Model Driven Testing of Time Sensitive Distributed Systems

In this paper we demonstrate an approach to model structure and behavior of distributed systems, to map those models to a lightweight execution engine by using a functional programming language and to systematically define and execute tests for these models within the same technology. This is a prerequisite for a smooth integration of model based development into an agile method. The novelty of this paper is the demonstration, how composition and state machine models for distributed asynchronously communicating systems can easily be mapped to a lazy functional language and then using standard testing techniques to define test on those programs. In particular distributed timing aspects and underspecification can be treated accordingly within a functional language, using a certain style of functions. 8.1. Model Driven Testing Software engineering in recent years has come up with a larger portfolio of techniques and methods to measure and improve or ensure quality of software products. Among those methods we have available inspection and review techniques for all artifacts that are produced during development. These techniques require clear qualChapter written by Borislav Gajanovic, Hans Grönniger and Bernhard Rumpe ity criteria as well as an appropriate process that clarifies the order of artifacts to be delivered and examined. Among the most promising techniques today, however, is the execution of "running" versions of system descriptions and the check of the execution result against the desired result. Agile methods [BEC 99a, COC 02, BEC 01, RUM 04] have furthermore successfully demonstrated that a full automation of the testing process is of high value in any larger and quality driven project. Only automated tests can efficiently be reused by developers. The portfolio of testing techniques has become large. It ranges from functional tests on abstract specifications over black box tests, stress tests, random tests down to glass box tests derived from the code. As testing has become a powerful technique, it was a natural idea to lift the use of testing techniques from the late coding phase to earlier phases, where fixing errors is less costly. However, starting early with testing means, we need executable artifacts early in the development process. If requirement specifications or at least design and architectural artifacts are executable, they need to be defined (a) precisely and (b) describe not only structural aspects but also behavioral issues. This calls for precisely defined modeling languages and for tools dealing with those languages. Tools need to be able to analyze wellformedness (thus checking context conditions) and to animate the model or to be able to map the model to code. The necessary properties of a model strongly depend on the context of the model usage. Models can be used for constructive or for test code generation. The desired properties here are fundamentally different. In case of a constructive code generation, we do have a compiler and as "side effect" modeling is equal to implementation. We can reuse the generated code as implementation if it is not only compatible with the development computers, but also with the target and is efficient enough. Instead, if we want to generate testing code, we do neither need complete and therefore very detailed models, nor do we need to restrict us to an executable modeling language. To understand the difference, consider a post condition for a method of the form a = b + c ∧ a, b, c, n > 2. Conditions like that are very easy to be checked, but it is usually extremely hard to construct a program that finds such values. So the choice of appropriate modeling languages and styles during the various development stages is important. Statecharts [HAR 87] are among the most interesting forms of descriptions for executable behavior. The use of underspecified Statecharts [PAE 94, KLE 97] with transition conditions and actions in (almost) first-order-logic allows to generate checking code only, but not constructive code. A clever choice of appropriate modeling techniques and their underlying semantics is therefore inevitable. For early checking of requirements, it is necessary to have a concise modeling technique and an efficient way of simulating the models at hand. In this paper we demonstrate an approach used to early validate requirements on distributed systems. This approach is exemplary, but demonstrates what can be achieved when using concise, compact modeling techniques in early phases, tools for transforming modeling techniques to executable languages, and a lean process to develop and use the models during the development adequately. To demonstrate the approach, we choose a relatively simple, but not too simplistic protocol, namely the Alternating Bit Protocol (ABP) [BRO 01]. The two modeling languages used for structure and behavior are adapted versions of UML diagrams: the composite structure diagrams and (flat) Statecharts respectively state machines. As the protocol is useful for distributed asynchronously communication systems, we choose the use of streams as underlying technical domain, because it offers a very precise semantics as well as a good integration of composition, refinement and various styles of specification [BRO 01, RUM 97]. For a lean development, we use a Haskell [THO 99, BIR 98] interpreter to simulate the models. Haskell e.g. provides lazy evaluation of lists, which allows to almost perfectly simulate streams as potentially infinite observations over communication channels. The remainder of this paper introduces the concept of distributed systems (Section 8.2), the Alternating Bit Protocol (Section 8.3), the general approach on testing (Section 8.4) and the application of testing strategies on the ABP (Section 8.5). Finally our findings are discussed (Section 8.6). 8.2 Asynchronous Communication in Distributed Systems In this section we briefly introduce the used semantic framework that describes on asynchronous communication as underlying communication principle of our framework. In a distributed system, we do have active components that communicate with each other through asynchronous sending and receiving of messages. We assume communication is based on unidirectional channels. For a precise modeling of their behavior, we use observation histories that describe what happens on these channels over time using the mathematical concept of streams. Streams are thus used to model the message-flow over those channels. The behavior of a component is specified through a description of the input-output relation on these streams. A stream is a finite or an infinite sequence of messages from some fixed finite set of possible messages (type). A stream-based specification of a component consists of a black box and an arbitrary (but finite) number of directed input and output channels. In figure 8.1 a composition of a system from several components is shown. With a single stream we describe the history on one channel, a component behavior is given by a function mapping its input streams to output streams. Certain restrictions apply on these functions to ensure the behavior is well-defined. E.g. a component (and thus a function) cannot undo messages that have been emitted, and it cannot react on future input (and thus predict the future). For any realizable component there is a stream-processing function with the same input/output behavior. Any state machine (with possibly infinite number of states) whose state transition function acts on messages appearing at the input and is yielding appropriate streams on the output can also be defined via a streamprocessing function [RUM 97, RUM 99]. Together with the fact that semantic definition through stream processing functions support composition of components via channels, we're able to use state machines and a variant of composite structure diagrams as a comprehensive specification language on a well-defined semantic basis. These stream processing functions are the primary concept to be mapped to Haskell for execution and testing. Furthermore, specification languages are particularly powerful if they allow us to abstract from implementation details and provide concepts for underspecification (alternatives, etc.). In terms of our underlying formalism, this means that a specification does not correspond to a single function, but to a set of functions that describes a set of possible implementations. The list given below describes a basic set of operators on streams useful for the specification of the components. For a comprehensive introduction to the streambased specification and development technique see [BRO 01]. [M] The set of all streams over a set of messages M. [] The symbol for the empty stream. [c] The stream consisting of a message c. head s Yields the first message of a non-empty stream s. tail s Returns the rest of a nonempty stream. #s Returns the length of a stream s (may be N ∪ {∞}). s1 ++ s2 The concatenation of s1 and s2. filter S s Filtering a stream s with respect to the members of a set S. Please note the special case #s = ∞ ⇒ s1 ++ s2 = s1. Also note that some operators like length # count infinite things and therefore cannot be used in an implementation. As an additional concept, we need the idea of time to model time-sensitive systems. Time can easily be modeled through the introduction of a special "message" here symbolized with Tk and pronounced as tick into the underlying set of messages. For that purpose we define an operator T for the introduction of so-called timed streams over a set of messages M: T M = { s | s ∈ [M ∪ {Tk}] ∧ #(filter {Tk} s) = ∞ A tick in a stream represents the incrementation of a global digital clock in the system. The time is never ending so there are infinitely many ticks in a timed stream. Timed streams are nothing more than normal infinite streams with a special structure. Hence, all operations introduced in the previous section can be applied to the timed streams as well. 8.3 The Alternating Bit Protocol In this section we describe how to apply our approach to a simple version of the Alternating Bit Protocol that can be found in [BRO 01, BRO 93]. We use the Alternating Bit Protocol here as a simple example of a time sensitive distributed system which transmits data safely over unreliable media. The black box specification of the ABP is simple: Abstracting from possible delays, the ABP is the identity. An appropriate specification of the ABP is therefore given through a set of stream processing functions: